Send WPT over IP

Sending waypoints & routes over IP

This User Page attempts to summarize this CF thread: http://www.cruisersforum.com/forums/f134/sending-waypoints-routes-over-ip-177080-2.html[2076]

It started with a question

As far as I can tell there is no way to send waypoints or routes over IP? Even if I type the IP connection in the box, it doesn't appear to send anything. Is there a way you can add this?

I ask because I have a Simrad NSS8 connecting using wifi and everything looks great except that. It's listening for NMEA183 and 2000 strings over IP so I think if there was a way to send strings it would update. I want to use this to create routes to port over to chartplotter as this is way nicer than doing it all on the CP

First answer

IIRC the NSS Simrad wont accept waypoint or route data via wifi. Sorry, the only way is to create it in opencpn and copy it to an SD or USB drive, and plug that into the Simrad. Less than ideal, but the Simrad will not allow file transfer, and navico doesn't seem interested in fixing it. Matt Paulin

Second Answer

There's a way, but not straightforward.

  1. We agree there's no way to convince the waypoint/route manager to contact a network port instead of a serial COM port. That would be a feature request using Flyspray but I tested and solved it this way: (I'm on Windows so all refers to that.)
  2. Have one OpencCPN main instance open, call it O-main.
  3. Have an OpenCPN portable instance open, call it O-port. How to set up a portable instance for simultaneously use with a O-main on Windows is another story. If you don't know pls read wiki or ask me here.
  4. Use a free virtual serial port app set up as a COM1 bridge to COM2.
  5. Have the waypoint to be copied in O-port, and from there sent the WP to COM1.
  6. In O-main use two connections,
    1. COM2 for incoming messages
    2. Net-IP-UDP connection for output, see screen shot below.
    3. On the same image you can see what happened in the O-main NMEA debug window.
    4. A WP coming in on COM2 and directly reflected out to the IP-port. (Although in opposite order but that's the same second so windows print can be random.)

opencpn:files:gallery_user:send_nmea_com_udp.png

If your Simrad is not listening to UDP you have to set the IP connection as TCP instead. It is not the most convenient way and there certainly other solutions. Håkan

Great or not but I would like to see 'send to IP' (wpts and routes) in OpenCPN one day. Barnakiel.

Third Try

Do you think the same could be achieved if: With one instance of OpenCPN

  1. COM 1 (real port)
  2. COM2 (virtual port, bridged)

to the same/one instance of OpenCPN?

COM 2 to be created by a virtual port software.
Then define one com as 'out' another as 'in' under OpenCPN?
Is the second (portable instance) of OpenCPN absolutely required? Barnakiel.

The Problem

opencpn:files:gallery_user:send_nmea_com.png

No, it could not be achieved. See screenshot below, where one WP was sent via COM1 (to “GPS”) and it's received by COM2 and directly sent out by UDP and COM1 and received by COM2 and directly sent out by UDP and COM1 and so on……… - like a microphone/speaker feedback. (The double of each is NMEA debug window stammering, not real transmittance.) Håkan

Another way?

Use NavMonPC -Do you mean sending WPTs from OpenCPN to a virtual port on NavMon and let Navmon bridge these over to a net port? Yes.

Testing

Yesterday I did a lot of experimenting but failed to pick up a wpt over wifi. I think my challenge yesterday was that NavMon uses a separate Client / Server tcp configuartion and it only sends wpts out to the Server part. But I am connecting as a client - my router playing the server part. Today I will try to get it done over OpenCPN as you did. My nmea router logs all traffic, so I will see if/when a wpt sentence gets there.

More Testing

People - do as Håkan says.

I tested both methods

I have also tested NavMon method but it did not work.

Method A allows to send a WPT or a route to another device via IP (ethernet cable or a wifi link). In my case the other device is wired into a router.

I have tested sending from OpenCPN via a wifi nmea router. WPTs get to the other side fine (in our case the other side is a Garmin unit).

I hope OpenCPN developers could add IP to the 'send waypoints' functionality. It should be possible without much ado (? I think).

If by any chance you have already experimented with doing the same trick between two wireless devices I would love to hear your feedback on how the IP router should treat an incoming WPT. Is there anything like an 'echo' command that would send the WPT back over the network so that other connected devices could pick it up?

Example: sending wpts from one wireless device to another wireless device over a wifi router.

Barnakiel.

Another Idea

“If by any chance you have already experimented with doing the same trick between two wireless devices I would love to hear your feedback on how the IP router should treat an incoming WPT”

I suppose two wireless devices are devices still on the same network segment? (like 192.168.1.xx) In that case it's no problem using protocol UDP. UDP is like a radio broadcast without a specific receiver, everyone is listening as long they're tuned to the same port, like 10110.

The router doesn't care what's broadcast, but some (old?) routers has to be set up to admit UDP on the port(s) involved. Håkan

Yes, close to this, but not identical. I am in the following scenario: The devices:

  1. 2 x laptops running OpenCPN, both on same 192.168.x.x network,
  2. 1 x wireless router, AP; creator of the above mentioned network.

The intention: to send WPTs wirelessly between these two laptops.

So: I press send WPTs on one laptop. These WPTs go to the router all right (the router logs them). However, this router does not send them onwards to the other laptop, and so the other OpenCPN does not receive them.

This is due to how my wifi nmea router works: it muxes serial and net ports. So whatever appears on a serial, gets forwarded to a net and vice-versa. However things that appear on the net do not get forwarded back to the same net.

In other words, my router sends serial data to wifi OK and also wifi to serial works OK. What it refuses to do is taking up WPTs from one device on the wifi network and sending them onwards to another device on this network.

I am not sure how to bite this. Maybe the router should 'echo' the WPTs over the net. Or maybe my challenge is using TCP (not UDP). Or perhaps some kind of firewall settings on the router blocks me. Barnakiel.

What are you using on your router? Muttnik. TCP The router is set to AP mode. So my wifi devices are clients, the router acts as a server. Barnakiel.

OK.Sorted out. Now my router too forwards the WPT back to the network. So all instances of OpenCPN that are on this network receive it. But how do I get OpenCPN do display these waypoints?

I receive them (as seen in the nmea monitor window, phrase ECWPL, direction incoming) but they do not pop up on OpenCPN screen, nor do they come up in the WPTs menu. So I guess either bad WPT format, or else … time to dig into OpenCPN manual. Barnakiel.

Summary

Windows - Send Waypoints over IP? wifi? to Simrad NSS8. Simrad NSS8 with wifi …listening for NMEA183 & 2000 .. over IP. I want to create routes to port over to chartplotter.

NSS Simrad won't accept waypoint or route data via wifi, so use USB or SD to copy.

Method A
Hakan -suggested which works.

NavMonPC
Bridge
|  
|--Com1  <---WP --- Com1 O-PORT  (OpenCPN)
|  
|--Com2  ----WP --> Com2 O-MAIN  (OpenCPN) Net-IP-UDP ---> IP-UDP NSS8 (or use IP-TCP)

Method A allows to send a WPT or a route to another device via IP (ethernet cable or a wifi link). In my case the other device is wired into a router.

Method B
Barnakiel - Suggested and tried

   |--OUT ---->Com2 (virt)--> NavMonPC ---> Net IP-UDP 
|                  
Opencpn                      
|
|--IN <---Com1 (real)  

Hakan Not sure NavMon & OpenCPN can tap into the same port at once? I need OpenCPN to be on the net port because my nmea data comes in this way. Result: ONE WP via COM1 (to “GPS”)–>COM2–>UDP & COM1–>COM2–>UDP & COM1 … feedback loop.

Why Method B does not work: You can filter, but you do not, because you want the incoming stream to come in because it it is the incoming stream that OpenCPN outputs then, to IP. The problem is it also outputs to COM1 and so the WPT goes back to COM2 and again to IP, and so on and forth. So it loops. So method B (sending and receiving from same OpenCPN instance) is a no no.

Why reconnect back to OpenCPN: Because OpenCPN cannot send WPTs to IP. But it does forward on IP WPTs received on a serial port. Except that the incoming WPT must be sent from another instance (or another program). If you try doing this from one instance of OpenCPN you run into above mentioned plan B limitation.

Fully faulty method B (one OpenCPN instance - this loops back).

Method C
Two Wireless devices Example: sending wpts from one wireless device to another wireless device over a wifi router.

Wifi --ip-udp-->  wifi router -- ip-udp --> wifi

Same trick between two wireless devices. How the IP router should treat an incoming WPT. Is there anything like an 'echo' command that would send the WPT back over the network so that other connected devices could pick it up?

Hakan Response: Two wireless devices on the same network segment (like 192.168.1.xx) no problem using protocol UDP. UDP is like a radio broadcast without a specific receiver, everyone is listening as long they're tuned to the same port, like 10110. The router doesn't care what's broadcast.

Method D

 2 x laptops running OpenCPN, both on same 192.168.x.x network
1 x wireless router, AP; creator of the above mentioned network.

The intention: to send WPTs wirelessly between these two laptops. Wpt sent is not recieved… due to how my wifi nmea router works: it muxes serial and net ports. So whatever appears on a serial, gets forwarded to a net and vice-versa. However things that appear on the net do not get forwarded back to the same net. serial —> wifi - OK wifi —> serial - OK IP UDP serial —> IP UDP serial - NO (and the reverse) ..due to firewall settings on the router? Using TCP and the router is set to AP mode. So my wifi devices are clients, the router acts as a se rver. — Changed to UDP Broadcast (incorrect) FCG Now my router too forwards the WPT back to the network. So all instances of OpenCPN that are on this network receive it. Barnakiel

Correction: I am using TCP. I have found the solution though. Now I do get the WPT into the other device but … (read on). But the WPTs (that do get received as proven by content of the nmea monitor window on the receiving machine) do not get shown in the receiving OpenCPN - not on the screen nor in the WPTs menu. (I did not have Internet connection earlier and could not see what OpenCPN manual says about receiving waypoints into OpenCPN and getting them displayed.) (My Garmin unit just displays a received WPT as soon as it gets transferred.)

OpenCPN cannot Receive waypoints

I had a long search of the manual. I cannot find any 'how to receive waypoints' reference. It seems to only talk about sending waypoints to say a GPS unit. The point is I want the reverse - I want to receive waypoints over the net (or wire) and see them displayed in 'my' OpenCPN.

Maybe it cannot be done. Barnakiel

Barnakiel…Nothing like that is implemented, OpenCPN does not do anything with the WPT sentences it receives. Feature request in flyspray is the way to change it… Pavel

Working Method

See Conceptual Diagram

OpenCPN connected to a net port,
- virtual COM A and COM B bridged,
- connect port B only to OpenCPN.
Now go into OpenCPN click the waypoints you want transferred and specify "send to COM A"

Yes - works fine (of course ) WPs and routes are nicely transferred to network and since A is not “seen” by O, no endless feedback. A straight forward solution to test if the IP message can be collected by the Garmin(?) gadget. If it works and you want to skip OCPN multiplexer and pay a fee there are a couple of virtual serial to IP out there. (The free one used to be limited to one serial bridge only) Håkan

Clarification

The setup:

  1. OpenCPN connected to a net port,
  2. virtual COM ports (say A and B), bridged,
  3. connect port B only to OpenCPN.

Now go into OpenCPN click the waypoints you want transferred and specify “send to COM A” (NOT Com B!)

     | <----> IP-UDP/TCP Network (nmea data comes in)
|
OpenCPN
|              __________
|--Com B out-->| NavMonPC  |--> Com A out to Chartplotter?
Bridge

The “bridge” can be NavMonPC connecting to Virtual ports Com A and Com B . NavMonPC can be on the same computer as OpenCPN, just connecting the two virtual ports.

Barnakiel: In theory yes, but NavMon did not do the job well at all. The other software (HDD Software Virtual Serial thingy) did well though.

Setup to Send Waypoints over IP:

  1. OpenCPN, ver 4.4
  2. Win 8.1
  3. HDD Software Virtual Serial bridge

Procedure:

  1. Start the bridged virtual COMs up first.
  2. Connect OpenCPN to one of the COMs and to the net port.
  3. OpenCPN connects to the net interface and to ONE only of the bridged virtual COMs.
  4. Send the WPTs to the OTHER virtual COM. NOT to the one that you connected OpenCPN to.

Simrad NSS8 connecting using wifi and everything looks great except that. It's listening for NMEA183 and 2000 strings over IP so I think if there was a way to send strings it would update. (…) If it connects to GoFree wifi bridge then the solution we posted should work. I do not have NSS8 at hand to test it though.

Conceptual Diagram:

opencpn:files:gallery_user:send_wpt_over_ip.gif

Sending to GPS Serial Com1

opencpn:files:gallery_user:send_transferring.gif

Result of Send to GPS

opencpn:files:gallery_user:send_transferred.gif

opencpn:files:gallery_user:send_connections.gif

Simrad NSS Chartplotters

I am looking at the image. I have also had a look at NSS manual. The manual says:

  1. WPTs get transmitted over the SERIAL port,
  2. WPTs on Ethernet are NOT bridged
    1. but it fails to say if they are utilized, this is question No1 for Simrad support,
    2. surprisingly, the list of accepted nmea sentences does NOT mention WPL.

So, we are sending WPL but it is not listed as a valid waypoint sentence in NSS manual, and NSS does not bridge the WPT sentence in any case. (This does not imply the sentence is used / not used).

I have no idea what sentence NSS uses for WPT transfer then - maybe one of N2K sentences? A good question No2 for Simrad support.

See dumps attached. Pretty self explanatory. The way we are trying (using WPL nmea 183) via Ethernet, it cannot get done. You may be able to send WPTs via the N2K link or else using a different (but which?) nmea 183 sentence.

opencpn:files:gallery_user:send_nss_bridging.jpg

opencpn:files:gallery_user:send_nss_nmea.jpg

opencpn:files:gallery_user:send_nss_waypoint_receive.jpg

OpenCPN neither sends nor receives WPTs via the net interface. It does send WPTs via the serial interface. It does not receive WPTs over the same interface (or else: it receives them but does not utilize them). Not sure you must talk in the manual about functionality not present. This would make any manual very very long.

  1. After more investigation I am kinda cursing I didn't get a Vesper XB-8000 for my AIS transponder, as it translates RMB and WPL sentences as well as being a wifi gateway. I could have just sent IP data there using the workarounds above and I think it would have worked. As well as giving me an anchor alarm that doesn't use my phone gps, which is bad.
  2. Instead I have an AIT2000 and the GoFree Wifi, neither of which does translation. And I can't get the NSS8 to accept the WP/route data using the above instructions, despite the fact it says it does over nmea183.
  3. It does, BUT at the same time it fails to show a WPL sentence on the list of accepted/incoming NMEA183 sentences. You want your Simrad dealer to tell you how this is done.
  4. Like Raymarine and (now) Garmin, they are not very clear with explaining their interconnectability, for a good financial reason.
  5. Every time a company moves on from niche to mainstream, they immediately start pushing us to purchase more of their equipment (by e.g. giving unclear, vague or wrong interconnect-ability info). Or else, as soon as a company grows big enough, there will be enough fools there within and they all end up writing instruction manuals and working in the client support department.

GoFree

If it connects to GoFree wifi bridge then the solution we posted should work. I do not have NSS8 at hand to test it though.

Report: Tried the above, don't think it will work - I think it's an NSS issue, as the nmea debug window looks correct. I'm not sure why it wouldn't update as it's listening for nmea183 strings but as you see below I think i'm sending them correctly

I am looking at the image. I have also had a look at NSS manual. The manual says:

  1. WPTs get transmitted over the SERIAL port,
  2. WPTs on Ethernet are NOT bridged (but it fails to say if they are utilised), (this is question No1 for Simrad support),
  3. surprisingly, the list of accepted nmea sentences does NOT mention WPL.

So, we are sending WPL but it is not listed as a valid waypoint sentence in NSS manual. And NSS does not bridge the WPT sentence in any case. (This does not imply the sentence is used / not used). I have no idea what sentence NSS uses for WPT transfer then - maybe one of N2K sentences? A good question No2 for Simrad support.

See dumps attached. Pretty self explanatory. The way we are trying (using WPL nmea 183) via Ethernet, it cannot get done. You may be able to send WPTs via the N2K link or else using a different (but which?) nmea 183 sentence.

Quote by Muttnik:

Don't know where this goes….

…That doesn't sound right. So you have a server X and clients A and B. A sends to X but then B doesn't receive from X?

  1. There is no a problem with kplex - the manual states clearly loopback must be specified explicitly as no loopback is default on TCP interfaces.
    1. It was not part of the initial thread content but I brought it in as I did not get waypoints displayed on receiving (remote) OpenCPN instance(s). Only later, with exquisite support from Pavel, I learned that O

Barnikiel wrote: Look up my Method X[2077] post above which may allow us to apply Hakan's solution while doing everything from one OpenCPN instance, with a virtual bridged COM set. My OpenCPN install is on Win8.1- I can test again on Win XP SP3 later and on Android. Perhaps someone on Linux could chime in.

Conditions:

  1. OpenCPN connected to a net port,
  2. virtual COM ports (say A and B), bridged,
  3. connect port B only to OpenCPN.

Now go into OpenCPN click the waypoints you want transferred and specify “send to COM A”

Yes - works fine

  1. WPs and routes are nicely transferred to network and since A is not “seen” by O, no endless feedback.
  2. A straight forward solution to test if the IP message can be collected by the Garmin(?) gadget.
  3. If it works and you want to skip OCPN multiplexer and pay a fee there are a couple of virtual serial to IP out there. (The free one used to be limited to one serial bridge only)